The following abbreviations are herewith defined, at least some of which are referred to within the following description of the prior art and the present invention.
3GPP Third Generation Partnership Project
ADC Application Detection and Control
AVP Attribute Value Pair
CCA Credit Control Answer
CCR Credit Control Request
CE Content Enrichment
DPI Deep Packet Inspection
GB Giga Byte
GGSN Gateway GPRS Support Node
IMSI International Mobile Subscriber Identity
IP Internet Protocol
IP-CAN Internet Protocol Connectivity Access Network
KBPS Kilo Bytes Per Second
MB Mega Byte
MS Mobile Station
MSISDN Mobile Station Integrated Services Digital Network number
PCC Policy and Charging Control
PCEF Policy and Charging Enforcement Function
PCRF Policy and Charging Rules Function
PDN GW Packet Data Network Gateway
PDP Packet Data Protocol
QoS Quality of Service
RAA Re-Authorization Answer
RAR Re-Authorization Request
SAPC Service Aware Policy Controller
SASN Service Aware Support Node
TSR TDF Session Establishment Request
TSA TDF Session Establishment Answer
SPR Subscriber Profile Repository
TDF Traffic Detection Function
UE User Equipment
The technical specification 3GPP TS 23.203 “Policy and Charging Control Architecture” (version V12.4.0; March-2014) discloses a Policy and Charging Control (PCC) architecture for use in a telecommunications system which allows among other things the application of charging and policies to the data flows of data sessions of their users. FIG. 1 (PRIOR ART) illustrates one of the PCC architectures 100 disclosed in 3GPP TS 23.203 (version V12.4.0; March-2014) which specifies the PCC functionality for the Evolved 3GPP Packet Switched domain, including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses. The PCC architecture 100 comprises these main entities: a Policy and Charging Rules Function 102 (PCRF 102), a Policy and Charging Enforcement Function 104 (PCEF 104), a Gateway 105, and a Traffic Detection Function 106 (TDF 106). Briefly, the PCRF 102 behaves as a Policy Decision Point (PDP), or policy server, which stores user policies and determines which user polices are to be applied in each data session. The network nodes implementing the PCEF 104 and/or the TDF 106 functionalities route data traffic flows to and from end users and behave as Policy Enforcing Points (PEPs) of the user policies. In addition, the PCC architecture 100 comprises an Online Charging System 108 (OCS 108), an Offline Charging System 110 (OFCS 110), a Subscription Profile Repository 112 (SPR 112), an Application Function 114 (AF 114), and a Bearer Binding and Event Reporting Function 116 (BBERF 116). The contents of the aforementioned 3GPP TS 23.203 (version V12.4.0; March-2014) are hereby incorporated by reference herein.
The PCRF 102 and PCEF 104 have between them a Gx reference point which is defined in 3GPP TS 29.212 “Policy and Charging Control Reference Points” (version V12.4.0; March-2014) (the contents of which are incorporated by reference herein). In particular, the Gx reference point is used for the provisioning and removal of PCC rules from the PCRF 102 to the PCEF 104 and the transmission of traffic plane events from the PCEF 104 to the PCRF 102. Plus, the Gx reference point can be used for charging control, policy control or both. The Gx reference point is based on RFC 3588 “Diameter Base Protocol” September 2003 (the contents of which are incorporated by reference herein).
The PCC architecture 100 also implements DPI (Deep Packet Inspection) technology which supports packet inspection and service classification where IP packets in the data sessions of end users are classified according to a configured tree of rules so that they are assigned to a particular service session. DPI has been standardized in 3GPP Rel-11, the so-called TDF 106, which refers to a stand-alone node. The DPI functionality can also run co-located with PCEF 104 for details reference is made to 3GPP TR 23.813 “Study on Policy Solutions and Enhancements” (version V11.0.0; June-2011) (the contents of which are incorporated by reference herein). A new reference point (Sd) has been defined for use between the stand-alone TDF 106 and the PCRF 102.
More specifically, the DPI function classifies IP packets into services and enforcement actions can be performed based on the detected services. One example of an enforcement action is service throttling in which IP packets classified to a certain service are bandwidth limited. It is also possible to throttle or limit the bandwidth of the whole bearer which is referred to herein as bearer throttling. A problem associated with this bearer throttling (bearer bandwidth limitation) and service throttling (service bandwidth limitation) in the current-state-of-the-art is described next with respect to FIG. 2 (PRIOR ART).
Referring to FIG. 2 (PRIOR ART), there is illustrated a basic diagram of a telecommunications system 200 which is used to help explain the problem associated with the current-state-of-the-art in relation to bearer throttling (bearer bandwidth limitation) and service throttling (service bandwidth limitation). The telecommunication system 200 comprises an IP Backbone Core Network 202 (includes a SGSN 204), the gateway 105 (includes the PCEF 104), the PCRF 102, the SPR 112, the TDF 106, and IP networks 206 (internet 206). As shown, the end user's UE/MS 208 connects to the IP Backbone Core Network 202 (includes the SGSN 204) which is connected to the gateway 105 (includes the PCEF 104). The gateway 105 (e.g., GGSN 105) is connected to the PCRF 102 and the TDF 106 respectively by the Gx reference point and a Gi/Sgi reference point. Also, the PCRF 102 is connected to the SPR 112 and the TDF 106 respectively by a Sp reference point and a Sd reference point. The TDF 106 is connected to the IP networks 206 (internet 206) by the Gi/Sgi reference point. It should be appreciated that the telecommunication system 200 includes many other components but for clarity only the components needed to help explain the problem associated with the current-state-of-the-art have been described herein.
As mentioned above, per the current 3GPP PCC functionality the bearer throttling (bearer bandwidth limitation) applies to the whole bearer and the service throttling (service bandwidth limitation) applies to a specific service. In this regard, the operators offer their customers flat tariffs for data access (e.g., a general internet package/bundle). This general internet package/bundle is valid for a certain time period (typically monthly) and typically bearer throttling is applied when the user's UE/MS 208 consumes a certain amount of volume (e.g., limit bearer bandwidth to 128 kbps when the user's UE/MS 208 consumes 1 GB during the monthly period). In addition, to the above general internet package/bundle, the operators offer their customers per service packages/bundles/add-ons (e.g., Facebook add-on, Twitter add-on, TV add-on etc. . . . ). These service add-ons typically have similar characteristics as compared with the general internet package/bundle (e.g., limit Facebook bandwidth to 64 kbps when the user's UE/MS 208 consumes 100 MB of Facebook data during the monthly period).
However, when the user buys a service add-on and the user consumes the data limit for the general internet package but not for the service add-on then a problem occurs where bearer throttling is imposed on all of the user's active services including the service add-on (e.g., Facebook bandwidth is limited even when the user's UE/MS 208 has not consumed the allotted 100 MB of Facebook data during the monthly period). Following is an example which further illustrates this problem:
Assume a flat tariff: service add-on+active service 1+active service 2=1 Gb. This can trigger selection of a bearer for 1 Gb.
Tariff Service Limits:
Service add-on: 400 Mb
Active Service 1: 500 Mb
Active Service 2: 300 Mb
The user's UE/MS 208 starts running these services and, at a certain point in time, the user's UE/MS 208 has consumed:
Service add-on: 200 Mb
Active Service 1: 500 Mb
Active Service 2: 100 Mb
At this point in time, service throttling is applied to active service 1 because it has reached its individual limit of 500 Mb. Service throttling does not apply yet to the service add-on and active service 2, and bearer throttling does not apply because the overall limit of 1 Gb has not been reached. This is illustrated in FIG. 2's non-problematic case.
The user's UE/MS 208 continues running these three services and, at a certain point in time, the user's UE/MS 208 has consumed:
Service add-on: 250 Mb
Active Service 1: 600 Mb (the latest 100 Mb with slower bandwidth)
Active Service 2: 150 Mb
At this point in time, service throttling is still applied to active service 1 because it has surpassed its individual limit. Service throttling does not apply yet to service add-on and active service 2 because they have not reached individual limit. However, since the overall consumption has reached 1 Gb (600 Mb+150 Mb+250 Mb) bearer throttling must be applied to service add-on, active service 1 and active service 2. This is illustrated in FIG. 2's problematic case.
As can be appreciated, the problem with the current-state-of-the-art is that, by limiting the bearer bandwidth for all services, the active service add-on(s) are also limited even if its individual limiting conditions have not yet been reached, and the end user perception is that the tariff agreements are not being respected for their service add-on(s). This negative end user perception can negatively affect the deployment of service add-on(s) as currently offered. Accordingly, there is a need to address these problems and other problems associated with the current PCEF 104, TDF 106, and PCRF 102. This need and other needs are satisfied by the present invention.